The following meanings for the abbreviations used in this specification apply:
ACR Accounting Request
AVP Attribute-Value Pair
CCA Credit-Control Answer
CCA-I Credit-Control Answer—Initial Answer
CCA-U Credit-Control Answer—Update Answer
CCR Credit-Control Request
CCR-I Credit Control Request—Initial Request
CCR-U Credit Control Request—Update Request
CP Charging Profile, also known as Charging Behaviors Profile
CTF Charging Trigger Function
DCCA Diameter Credit-Control
DOIC Diameter Congestion Information Conveyance
G-S-U Granted-Service-Units
IP-CAN Internet Protocol Cellular Access Network
KPI Key Performance Indicator
OC Overload Control
OCS Online Charging System
OLR Overload Report
PCEF Policy and Charging Enforcement Function
PGW Packet Data Network Gateway
RG Residential Gateway
In the following, also some terms as used in the present application are defined:
Abatement: Reaction to receipt of an overload report resulting in a reduction in traffic sent to the reporting node. Abatement actions include diversion (in which the reacting node selects alternate destinations or paths for requests) and throttling (in which the number of requests sent by the DIOC reacting node is limited).Overload Control State: Internal state maintained by a reporting or reacting node describing occurrences of overload control.Overload Report (OLR): Overload control information for a particular overload occurrence sent by a reporting node.Reacting Node: A Diameter node that acts upon an overload report.Reporting Node: A Diameter node that generates an overload report. (This may or may not be the overloaded node.)Online Charging System (OCS): the entity that performs real-time Credit-Control. Its functionality includes transaction handling, rating, online correlation and management of subscriber account balances.Gy: Online charging reference point between a PCEF and an OCS.Ro: Online charging reference point between a 3GPP network element (e.g. PGW) and the OCS.
Embodiments of the present invention relate to “Diameter Overload Control in Charging Applications”, which is partially covered in 3GPP TR 29.809, and in Internet Draft IETF Draft draft-ietf-dime-ovli-08, and refers in particular to an implementation of the general DOIC protocol (Diameter Congestion Information Conveyance) in diameter applications.
DOIC proposes that an overload report is sent in the answer to a diameter message. For diameter charging applications, it means that it is a response to an accounting or credit control request, for an already established diameter session.
In case the diameter server is in overload situation, it will start replying to its active diameter sessions with overload indications in order to reduce the traffic.
When new bearers are created at the PGW, an initial message is sent towards the diameter server. Those diameter messages towards an overloaded diameter server can not be prevented according to the approved DOIC algorithm which 3GPP will now standardize. This happens because as it is a first message for a session, there is no previous reply which can be used by the diameter session to apply the DOIC abatement algorithm.
Therefore, there is a problem that DOIC does not solve. When the diameter server is in overload state, the new bearers will keep sending diameter messages to the congested server without applying DOIC, making the overload situation worse.
Diameter Base Protocol (RFC 3588/RFC 6733) defines DIAMETER_TOO_BUSY as the diameter congestion control used by all diameter applications (including diameter charging applications). For failure at OCF (Online Charging Function, Ro/Gy interface), at reception of such error code, the diameter client initiates the configured failure handling mechanism, which is defined by 3GPP and is application specific (See 3GPP TS 32.251 Annex B for the failure handling mechanism applied to Diameter online charging application).
Failure handling mechanisms, in case there is no secondary server to take over the session, will mean that the subscriber services will be terminated. The DCCA termination is immediate, and the Bearer termination can be immediate (failure handling TERMINATE), or after a timer expires (failure handling CONTINUE).
The result is that in case of congestion (or temporal failure) in a diameter charging application, subscriber services are impacted (bad customer experience), and there is an economical impact to operators (due to charging interfaces not working as designed) this situation extends until the bearers are deleted. If congestion at OCS eases, there is no possibility to regain credit control for the active bearers that were affected due to OCS overload).
This overload congestion mechanism (which 3GPP tries to improve) is illustrated in FIG. 6.
In particular, FIG. 6 illustrates 3GPP behavior with legacy overload control (RFC 3588) and shows a signaling flow between the OCS (the reporting node) and the PGW (reacting node). In A1, an IP CAN Bearer-1 is created. For this, the PGW sends a credit-control request (CCR) to the OCS for creating the IP CAN Bearer-1 (CCR1-I), and the OCS responds with a credit-control answer (CCA) for the IP CAN Bearer-1 (CCA1-I). In A2, credit control is ongoing for RG1 (residential gateway for which the IP CAN Bearer-1 was created). If due to a charging trigger an update is required, corresponding CCR1-U/CCA1-U messages are exchanged between PGW and OCS.
In A3, an overload is detected at the OCS. In A4, a request for more quota for RG1 is created, and in A5, a corresponding request CCR1-U(RG1) is sent to the OCS. Since the OCS is in overload, the OCS responds with CCA1-U DIAMETER_TOO_BUSY.
Thus, there is a need to improve overload control or congestion control in such a case.